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(57) In a transaction processing system that in- 
cludes a plurality of client processes (40) coup- 
led to a server process (42), the server process 
supports execution of transactions generated 
by the client processes. The server process 
includes, for each client process being served, 
one or more transaction message control 
mechanisms. Each transaction message control 
mechanism includes a named processing 
object that includes a name identifying the 
object. The named processing object also in- 
cludes an input process that receives all trans- 
action request messages naming the object and 
identifying the originating client process. The 
input process dispatches a transaction process 
for each transaction request message received 
from the respective client process. Each trans- 
action process oversees transaction execution 
and receives transaction output. A transaction 
process provides a transaction output message 
for the originating client process. In a non- 
sync'd mode of operation, transaction proces- 
ses may synchronously send transaction output 
messages to client processes. In a synchronized 
mode of operation, one transaction process at a 
time sends output messages under control of 
an output process in the named processing 
object. The transaction message control 
mechanisms provide a bi-directional transac- 
tion message flow between server and client 
processes. 
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The invention provides a mechanism that can be manipulated as an object by a client process to control 
bi-directional transaction message traffic between the client process and a server process. The invention al- 
lows a client process to name the mechanism as an object at a server process. The named object (also referred 
to as a "Tpipe") includes the ability to receive transaction request messages and transaction output messages 
5 at the server process and to associate transaction output messages with their ultimate destinations. Thus, the 
association between transaction output and its recipient is not made by a server process but is, rather, left to 
the client process. 

The invention is embodied in both a mechanism and a procedure for bi-directional transport of transaction 
messages between server and client processes. 
10 The invention affords flexibility to a transaction processing system of the client/server model in that many 

transaction outputs may simultaneously flow through the same Tpipe. 

The invention allows a client process to create more than one Tpipe, thereby allowing distinctions to be 
made between transactions that occur naturally because of. for example, flow-control and synchronization dif- 
ferences. 

is The invention relieves the server process of responsibility for coupling a transaction output to an end user. 

The invention provides client processes with control over the output of their submitted transactions. 

In order that the invention may be fully understood a preferred embodiment thereof will now be described, 
by way of example only, with reference to the accompanying drawings in which: 

Figure 1 is a block diagram with a transaction-based, client/server database system; 
20 Figure 2 is a block diagram illustrating the invention in a representative operational environment; 

Figure 3 illustrates the structure of a transaction message; 

Figure 4 is a hybrid btock/flow diagram illustrating the operation of the invention according to a first mode; 
Figure 5 is a hybrid block/flow diagram illustrating operation of the invention according to a second mode; 
and 

25 Figure 6 is an illustration of another mode of operating the invention. 

The invention concerns a transaction processing system of the client/server type. An exemplary embodi- 
ment of such a system is illustrated in Figure 1. In Figure 1, a central processor, which may include, for example, 
the 3090/MVS product available from INTERNATIONAL BUSINESS MACHINES CORPORATION, is indicated 
by reference numeral 12. A server process 14 executes in the central processor 12. In the preferred embodi- 

30 ment, the server process comprises a database management system such as the IMS product available from 
INTERNATIONAL BUSINESS MACHINES CORPORATION. The server process is coupled by a communica- 
tions facility 16 to a peripheral processor 18 that executes a client process 19. Other peripheral processors 
20, 21 may be coupled to the communication facility 16 by way of a node 24. The server and client processes 
14 and 19 include respective communications interfaces 25 and 26 that implement an appropriate communi- 

35 cation protocol to support transfer of information between the processes. Such architecture also characterizes 
communications between any client process and the server process 14. (In the invention, client processes may 
execute at virtually any transaction processing system location. Thus, a client process can be located at a per- 
ipheral processor 18, 20, 21, for example, at a node such as 24, and in the central processor 12). 

The server process 14 supports transaction processing that affords client processes with the ability to 

40 access one or more databases such as the databases 27 and 28. The server process includes a database 
management system (DBMS) 29 that has at least a transaction manager 31 and a database manager 32. One 
or more application processes 33 and 34 execute to support user requests for database access. Thus, if a user 
access request is entered at the peripheral processor 18, the client process 19 executes, preparing a trans- 
action request to implement the access requested by the user. The transaction request is sent via a message 

45 to the central processor 12 and delivered to the server process 14. Transaction requests are passed to the 
transaction manager 31 through an input queue 35. The transaction manager evaluates a transaction request, 
dispatches a transaction process to execute the request via one of the applications 33, 34. Output for trans- 
action requests is queued at 36 and passed through the communications interface 25 and the communications 
facility 16 to the respective requesting client processes. 

so As will be appreciated by those skilled in the art, the client/server model of Figure 1 is application specific 

in that it incorporates a structured communication facility which may comprise, for example, a network to in- 
terconnect client and server processes. The invention is not intended to be limited to such a structure. Indeed, 
the invention does not contemplate any specific communications control mechanization. It is concerned es- 
sentially with the control of message traffic between client processes and a server process, no matter where 

55 the processes are located. 

The invention is illustrated in Figure 2 in the context of a client process 40 in a plurality of client processes 
and a server process 42, The client process 40 receives user requests that it structures into transaction request 
messages and provides to the server process 42. The client and server processes 40 and 42 implement trans- 
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With reference now to Figures 2 and 4 and to Tables Mil, the operation of the invention in Commit Mode 
I wiil be explained. Tables l-lll are pseudo-code descriptions of logic for, respectively, the server Tpipe process 
43, the Tpipe input process (PI), and a transaction process (Tprocess). The mode of operation for Commit Mode 
I is referred to as non-sync'd Tpipe. In the non-sync'd Tpipe mode of operation, all Tprocesses control the send- 
5 ing of the transaction response messages to the client process. Consequently, the output process (PO) is not 
used. The fiow transactions and output through a non-sync'd Tpipe is illustrated in Figure 4. The order and 
explanation of non-sync'd operation is as follows: 

1. The client 40 sends a transaction message for transaction x as an input to the server process 42. 

2. The transaction message is inspected by the server Tpipe process 43 whose logic is described in Table 
10 I. The server Tpipe process 43 verifies the presence of a Tpipe name in the message, consults the hash 

table 44 to determine whether the Tpipe has been named for the client process 40. If the name is not in 
the table, the Tpipe is created and its name is added to the hash table 44 for the client process 40. The 
transaction message is then enqueued to the input process ("PI") and PI is scheduled to run. Once a Tpipe 
has been created, it will remain linked by the hash table 44 to the client for which it was created for the life 
75 of the server process. 

3. PI takes the transaction message from its queue and dynamically creates a Tprocess ("Tprocess x") 
for transaction x. 

4. Tprocess x for transaction x is dispatched by PI to process the transaction. 

5. Tprocess x submits the transaction to the named application 52 where it may be enqueued at 55. 

20 6. The application 52 then provides through its output queue 56 a transaction output message to Tprocess 

x. 

7. Tprocess x then takes the transaction output message and processes it as required for return to the 
client process 40. 

8. Tprocess x then sends the transaction output message to the client processor 40. If more than one output 
25 message is required for transaction x. the output messages are enqueued on Tprocess x for transmission 

for the client process. Assuming that the client acknowledges messages, when ail transaction output mes- 
sages for transaction x have been acknowledged by the client, Tprocess x will be deleted. 
Figure 5 illustrates message flow with a sync'd Tpipe operating in commit mode 0. In this regard, the in- 
vention contemplates a need for sync'd Tpipes in order to resynchronize processing if either the client process 
30 or the server process terminates abnormally. 

For example, consider the scenario where a client process sends a transaction request message to the 
server process with a request for an acknowledgement. Assume that the transaction protocol requires the ser- 
ver to log the requested transaction and enqueue it prior to sending the acknowledgement to the client process. 
If the server process crashes before the acknowledgement is sent, both the client and server processes need 
35 to resynchronize by, for example, an exchange of sequence numbers. With ^synchronization, the client proc- 
ess might assume that the transaction was not received by the server process, in which case the client process 
may attempt to send the transaction a second time. If the transaction is enqueued a second time at the server 
process, this may result in an unacceptable condition such as where the same debit is made twice to an ac- 
count. In order to avoid this, the server process would, with reference to its log during ^synchronization, inform 
40 the client process that the transaction was successfully received. In this case, the client would treat the infor- 
mation as an acknowledgement. 

In the foregoing scenario, it would be necessary for the client and server processes each to maintain a 
copy of the last sent message and a record of the last received message in order to support resynchronization. 
This requires that all sending operations be properly serialized at the server process in that no message may 
45 be sent until an acknowledgement has been received for the previous sent message. Relatedly, all sent and 
received messages must be enqueued. This is accomplished in the invention by f unneling all output messages 
through the output process in the sync'd mode of operation. 

For a sync'd Tpipe, the output queue (POQ) that is controlled by the output process (PO) is used. Any Tpro- 
cess with a transaction output message in a sync'd mode Tpipe queues for permission from the output process. 
so When the output process grants permission to a Tprocess, only that Tprocess is allowed to send transaction 
output messages to a client process. 

The flow of transactions and output through a sync'd Tpipe is illustrated in Figure 5 and described as fol- 
lows: 

1. The server Tpipe process receives a transaction request message containing transaction x. 
55 2. The server Tpipe process notices that Tpipe A has been named for the transaction and attempts to locate 

that object. If not found, the object is dynamically created and entered into the hash table 44 for the re- 
questing client process where it remains for the life of the server process. 

3. The input process, PI, takes the transaction request message and dynamically creates a Tprocess for 

5 
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TABLE I 

Pseudocode for Server Tpipe Process 43, Fig. 2 

Receive Client's transaction (via XCF or any other 
Transport mechanism) . 

Verify that Tpipe name is specified in the transaction. 

Look up Tpipe name in hash table of Tpipe 's. 

If Tpipe does not exist then 

Create the Tpipe and add it to the Tpipes hash table. 
End if 

Enqueue the transaction to the Tpipe 's PI process and 
schedule that PI to run. 

Wait for another transaction. 



TABLE II 

Pseudocode for Input Process 47, Fig. 2 

Receive data on the input queue ( PIQ) . 

If data is a transaction then 
If Sync'd Tpipe then 

If PO is waiting for an Ack then 
Reject the transaction. 
Go to WAIT logic. 
Endif 
Endif 

Create a Tprocess for the transaction and chain 

it to the list of existing Tprocesses for the Tpipe. 

Schedule the Tprocess to run. 



Elseif data is an Ack from a 
If Sync'd Tpipe then 

If PO is NOT waiting for 
Reject the Ack. 
Go to WAIT logic. 
Else 

Notify the PO that its 
This will cause the PO 
Go to WAIT logic. 
Endif 
Endif 



Client then 
an Ack then 

expected Ack has arrived, 
to wake up and run. 



Locate the Tprocess who is awaiting the Ack and 
notify him that his expected Ack has arrived. 
This will cause the Tprocess to wake up and run. 

Elseif data is a command then 

Process the command 
Else 

Reject the data. 
Endif 

WAIT for more data on the PIQ. 
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TABLE III 

Pseudocode for Tprocess in Non-Sync 'd Mode 
fro^^e^^ 31 "^ A '"nation message has been received 

Enqueue the transaction to the server application . 
LOOP: WAIT for a notification _ 

giving output message. "PP- 1 - nation 

If if 0 ^K ati0n 13 for an Ac *' then 

Endif 

Elseif notification is for an application output .essage, 
Endif thS ° Utput "^age to client. 
Go to LOOP to wait for Ack. 



TABLE IV 

Pseudocode for Output Process ( PO ) in Sync'd Mode 
Receive Tprocess X's request on the POQ queue. 
Mark PO as giving up control to Tprocess X. 

Main Wait 

If Tprocess relinquishes control of po then 

ElftLf^ r qU68t ° n the P0 « and 9° to beginning 
Elf seif Pi has given Ack to PO then ginning. 

M«f^ TP ^° CeS3 38 no lon 9 er waiting for an Ack 
Endif 
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TABLE V 

Pseudocode for Tprocess in Sync'd Mode 

Initial processing: A transaction has been received from 
the PI. 

Log the transaction. Include Client's transaction sequence 
number in the log record. 

Enqueue the transaction to the Server application. 

LOOP: WAIT for a notification. 

Wake up as a result of a notification. Either the PI is 
giving an Ack, or a Server application is giving output 
message (when no other output message processing is taking 
place. I.e. if output message processing is in process, 
then the application will only enqueue the message to the 
Tprocessor ) 

If notification is for an Ack, then 

If another output message enqueued then 

Send the output message to the Client. 
Elseif no* more expected output messages, then 

Notify PO to relinquish control of output processing. 

Delete yourself. 
Endif 

Elseif notification is for an application output message, 
then 

Enqueue PO-control request to POQ and WAIT for PO to 
give us this control. 

Log output message with Tpipe's output sequence number. 
Send the output message to Client. 
Indicate in PO that he is now expecting an Ack. 
Endif 

Go to LOOP to wait for Ack. 



Claims 

1 . A transaction processing system comprising: a plurality of client processes for generating transaction re- 
quest messages, each transaction request message including a request to execute a transaction and an 
object name; 

a server process for executing transaction requests contained in transaction request messages 
from the client processes; 

an interprocess message exchange facility coupled to the client processes and the server process 
for providing client process transaction request messages to the server process and providing transaction 
output messages to the client processes; 

an input process in the named processing object for receiving all transaction request messages 
that include the object name and the identification at the respective client process; and 

dispatch means in the input process for dispatching a transaction process in response to a trans- 
action request message, each transaction process dispatched by the dispatch means being for receiving 
a transaction request message and for initiating a transaction for execution. 

2. A transaction processing system as claimed in claim 1 further comprising: 

routing means in the server process for routing transaction request messages according to proc- 
essing object names contained in the transaction request messages; 

a plurality of transaction message transport mechanisms in the server process, wherein each 
transaction message transport mechanism includes a named processing object that includes an object 
name identifying the named processing object and an identification of a respective client process. 
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activating an input process in the named processing object; 

providing all transaction request messages from the respective client that include the object name 
to the input process; and 

for each transaction request message received by the input process, dispatching a transaction 
process by providing the transaction request message to the transaction process for processing a trans- 
action requested by the transaction request message. 

A server apparatus for use in a transaction processing system, comprising: 

a message facility for receiving transaction request messages from client processes; 

means for creating a named processing object in response to a client process transaction request 
message, the transaction request message including a field identifying a respective client process and 
a name identifying the named processing object; 

an input process included in the named processing object and coupled to the message facility for 
receiving all transaction request messages from the respective client process that include the name iden- 
tifying the named processing object; and 

dispatch means in the input process for creating and dispatching a transaction process and for pro- 
viding a transaction request message to the dispatched transaction process for processing a transaction 
requested by the transaction request message. 

A client apparatus for use in a transaction processing system, including: 
means for receiving a plurality of transaction requests; 

means for generating transaction request messages addressed to a server process, each trans- 
action request message being generated in response to a respective transaction request and including: 
a first field identifying a requested transaction; and 

a second field for naming a processing object in a server apparatus, the processing object including 
an object name identifying a server transaction message processing mechanism and the client process; 

means for receiving transaction output messages form a server process and associating each 
transaction output message with a transaction request of the plurality of transaction requests. 

In a server apparatus for use in a transaction processing system, the server apparatus having means for 
coupling to a p lural it yof client processes for executing client-initiated transactions, a method for grouping 
transaction messages, the method comprising the server apparatus-executed steps of: 

receiving a transaction request message, the transaction request message including a field iden- 
tifying a respective client process and an object name; 

creating a named processing object in response to the transaction request message, the named 
processing object including the object name and identifying the respective client process; 

activating an input process in the named processing object; 

receiving a plurality of transaction request messages; 

providing all transaction request messages in the plurality of transaction request messages that 
include the object named to the input process; and 

for each transaction request message received by the input process, dispatching a transaction 
process by providing the transaction request message to the transaction process for processing a trans- 
action requested by the transaction request message. 
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(57) In a transaction processing system that in- 
cludes a plurality of client processes (40) coupled to a 
server process (42). the server process supports exe- 
cution of transactions generated by the client process- 
es. The server process includes, for each client process 
being served, one or more transaction message control 
mechanisms. Each transaction message control mech- 
anism includes a named processing object that includes 
a name identifying the object. The named processing 
object also includes an input process that receives all 
transaction request messages naming the object and 
identifying the originating client process. The input proc- 
ess dispatches a transaction process for each transac- 
tion request message received from the respective cli- 
ent process. Each transaction process oversees trans- 
action execution and receives transaction output. A 
transaction process provides a transaction output mes- 
sage for the originating client process. In a non-syne'd 
mode of operation, transaction processes may synchro- 
nously send transaction output messages to client proc- 
esses. In a synchronized mode of operation, one trans- 
action process at a time sends output messages under 
control of an output process in the named processing 
object. The transaction message control mechanisms 
provide a bi-directional transaction message flow be- 
tween server and client processes. 
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